home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14007 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: dscomsa.desy.de!x4u2!mernst
  2. From: mernst@x4u2.desy.de (Matthias Ernst)
  3. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Followup-To: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  6. Date: 28 Mar 1996 12:38:49 GMT
  7. Organization: DESY
  8. Message-ID: <4je18p$lnr@dscomsa.desy.de>
  9. References: <4j948d$t3d@trumpet.uni-mannheim.de> <1996Mar27.134800.18605@schbbs.mot.com>
  10. NNTP-Posting-Host: x4u2.desy.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. David L. Shang (shang@corp.mot.com) wrote:
  14. : In article <4j948d$t3d@trumpet.uni-mannheim.de> mw@ipx2.rz.uni-mannheim.de  
  15. : (Marc Wachowitz) writes:
  16. : > David L. Shang (shang@corp.mot.com) wrote:
  17. : > > But an exception is not necessarily an error. Sometimes it is an
  18. : > > condition that requires some extraordinary computation, a condition
  19. : > > that is not supposed for a regular case, [...]
  20. : > 
  21. : > Let's look at the problem with fresh eyes, without thinking immediately
  22. : > about using the technical feature called "exception" in a few programming
  23. : > languages.
  24. : > 
  25. : > Some routine (often supposed to be reused for different contexts) wants
  26. : > the "advice" of its caller (or the caller's caller etc.) how to handle an
  27. : > unusual condition ("advice" might imply activities, like a user query).
  28. : > 
  29.  
  30. : Couldn't agree more. That is what an exception handling is supposed to
  31. : do, and that is the case where exception handling is helpful. Back to
  32. : my original post, I analyzed two cases for exception handling:
  33.  
  34. : * the callee decides how to handle the exception; and
  35. : * the caller decides how to handle the exception;
  36.  
  37. : And I concluded that the second case is more important and useful.
  38.  
  39. I also agree but have some problem about the way the exception handler
  40. passes back information to the 'thrower'. Or, the other way around, how can
  41. the 'thrower' ask for dedicated information in an anonymous outer frame
  42. (a la 'Do you really not want to save your changes ?')
  43.  
  44. I fear, for retry-semantics the handler is too near to the thrower, too deep
  45. in the hierarchy to provide this information.
  46.  
  47. try
  48.   font = getfont(name, size)
  49. except exc: FontNotAvailable
  50.   ask_for_new_font(out name, out size)
  51.   -- Ask the user here ? We're deep in the functional part, not aware of our user interface
  52.   retry
  53. end;
  54.  
  55. With resumption-semantics the handler might alter the exception object:
  56.  
  57. try
  58.   init_interface -- which is a deep hierarchy
  59. except exc: FontNotAvailable
  60.   ask_for_new_font(out name, out size)
  61.   exc.new_font_name = name
  62.   exc.new_font_size = size
  63.   
  64.   resume
  65. end;
  66.  
  67. and somewhere in the hierarchy the thrower may try with the new font name.
  68.  
  69. while not_available(name, size)
  70.   exc = new FontNotAvailable(name, size)
  71.   throw exc -- exc will be filled out with new font information
  72.   name = exc.new_font_name
  73.   size = exc.new_font_size
  74. end -- while
  75.  
  76.  
  77.  
  78.  
  79. But I fear that at the toplevel all the handlers for missing information
  80. accumulate to a great mess.
  81.  
  82. Anyway termination semantics don't help further.
  83.    
  84. Solutions, anyone ?
  85.  
  86. -- Matthias
  87.  
  88.  
  89.  
  90.